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ACTIVE SERVER MANAGEMENT configuration changes made to the network that were stored 

in the central database 104. If there are a large number of 

BACKGROUND OF THE INVENTION DNS servers 102A-N and DHCP servers 1G3A-N, for 

1 Field of the Invention example 100, on the network, a bandwidth issue is created 

The present invention relates to the field information 5 al the central dalabasc 104 

networking and more specifically to transmitting configu- Therefore, it would be useful to an improved means of 

ration information between a central database and one or communicating between a database and one or more servers, 

more servers in a network. SUMMARY OF THE INVENTION 

2. Description of the Related Art 

In a typical network, a server directly communicates with A method and apparatus for managing IP addressing in a 
the central database in order to obtain configuration infer- network and effectively synchronizing communication 
mation. FIG. 1 illustrates an overall diagram of a conven- between a central database and one or more servers (such as 
tional Transmission Control Protocol (TCP)/Internet Proto- DNS and DHCP) is described. In one embodiment, a server 
col (IP) network 101 including one or more Domain Name manager acts as an interface between the one or more servers 
Service (DNS) servers 102A-N, one or more Dynamic Host and the central database. The server manager also synchro- 
Configuration Protocol (DHCP) servers 103A-N and a ™ zes requests for configuration information and configura- 
central database 104. Typically, the one or more DNS tion updates from the one or more servers and transmits the 
servers 102A-N and DHCP servers 103A-N on the network requests and updates to the central database through a single 
transmit requests for configuration information and send communication channel. The server manager then receives 
configuration updates to the central database 104. The the configuration information from the central database and 
central database 104 either transmits the requested configu- sends the information to the servers that issued the requests, 
ration information back to each server or it stores the The server manager also transmits the configuration updates 
configuration updates received from each server. from the one or more servers to the central database. 

, . . . t . , „ „,„iU^Ar Periodically, the server manager polls. the central database 

In the past, organizations relied on paper based methods 1S c , J a t - A ♦ *u ♦ i tf«u 

r ■ .D II a niirp c ; m „i,'flp,nh, for any changes m configuration made to the network. If the 

of managing IP addresses in a network. DHCP simplified the J 6 & . . 

management and assignment of IP addresses to clients by *™ r mana S er Ganges stored in the central 

eliminating the need for the network administrator to manu- *f base > ,t transrmts the changes to the appropnate servers, 

ally configure the network. With DCHP, when a client ™ c "™ mana g er als ° P?"* 5 ^ multrple requests at one 

* m • i 0 , , rt ^ mm „n,v a tP rt ,„r thA time and queues up any further requests based on the priority 

requests an IP address in order to communicate over the 30 , , n , . _, . • u * u *u 

4 , t^t,™ , u . u «j* of the work requested or the order in which they were 

network, a DHCP server answers the request by providing - a 

network configuration information that was obtained from a received. 

database and dynamically assigning an IP address to the BRIEF DESCRIPTION OF THE DRAWINGS 
client. Each DHCP server manages a range of client 

addresses and can pick any address from that range as long 35 FIG. 1 is an overall diagram of a conventional TCP/IP 

as it is not being used by a another client managed by that network. 

DHCP server. Since the address is dynamically assigned, the FIG 2 is an overall diagram of a TCP/IP network as may 

client can have a different IP address each time it logs on to implement the present invention. 

the network. Along with the ability to dynamically assign IP pjQ 3 j s a fl ow diagram illustrating the steps for a server 
addresses, a DHCP server also supports static IP address that 40 t0 ser ver manager login process as may be utilized by an 
have been assigned to one particular client on the network. embodiment of the present invention. 
Based on the configuration information received from the piq 4 is a flow diagram illustrating a method for corn- 
database, the DHCP server can automatically assign a spe- mU nicating configuration information from the central data- 
cific IP address to a specific client. base tQ ft DHCp through the server manager as may 

DNS also simplified the management of networks by 45 be utilized by an embodiment of the present invention, 

translating domain names into IP addresses. Since the DNS nG 5 ^ a flow dia m illustrating a method for com- 

server contains a list of domain names and their associated municati configur ation updates from the central database 

IP addresses, a host or client can be located through by its (o a DNg ag be milized b an embodiment of the 

domain name rather than its IP address. Any given domain preserJ t invention 

name could be associated with more than one IP address and 50 „ T ^, •„ , +u a e . • 

.„ . n ^„ nta A « tu«« ™* FIG. 6 is a flow diagram illustrating a method for retnev- 

anv IP address could be associated with more than one _ . & , . t . w ,u 

V a iwc „«^o^e tu. A nm .; n «*rr^ 9n H mg an Y configuration changes in the network from the 

domain name. A DNS server updates the domain name and , , , . r . • iL . 1 j . u j . 

IP address associations by periodically polling a central delta-logging facility in ithe centra database and transmuting 

database containing configuration information for the net- the ^° the ™» on the " ctwo * ™ m ^ «* utlhzed b * an 

work. When a new clienfis assigned an IP address by a 55 embodiment of the present invention. 

DHCP server, the new configuration information is stored in FIG, 7 is a flow diagram illustrating a method for deter- 

the central database. Each DNS servers on the network poll mining the operational status of the DNS and DHCP servers 

the central database for configuration changes, If a new IP on the network and transmitting the status information to the 

address was assigned to a client managed by a DNS server, NMS as may be utilized by an embodiment of the present 

the DNS server updates the domain name with the new IP 60 mvenll0n - 

address or updates the IP address with the new domain FIG. 8 is a flow diagram illustrating a method for authen- 

□ame. 2 ticating a user and binding the user to the IP address 

In mid-to large-scale networks, a significant number of dynamically assigned to it by a DHCP server as may be 

transmissions between the central database 104 and the DNS utilized by an embodiment of the present invention, 

servers 102A-N and DHCP servers 103A-N occur. Each 65 For ease of reference, it might be pointed out that refer- 

DNS server 102A-N and DHCP server 103A-N must indi- ence numerals in all of the accompanying drawings typically 

vidually contact the central database 104 to obtain any are in the form "drawing number" followed by two digits, 
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xx; for example, reference numerals on FIG. 1 may be 
numbered lxx; on FIG, 3, reference numerals may be 
numbered 3xx. 

DETAILED DESCRIPTION OF AN 
EMBODIMENT OF THE PRESENT INVENTION 

FIG, 2 illustrates a TCP/IP network configured in accor- 
dance with the methods and apparatus discussed herein. 
Although described with reference to certain specific 
embodiments, those skilled in the art will recognize that the 
present invention may be practiced without some or all of 
these details and further, the present invention may be 
utilized in alternative networks. In one embodiment, the 
network can contain a plurality of servers that must access 
the central database in order to obtain configuration infor- 
mation. In order to reduce the number communication 
channels going to the central database, a server manager can 
be introduced. The server manager would communicate 
directly with the plurality of servers and the central database 
and transmit any requests from the servers to the central 
database. Therefore, the central database only would need to 
communicate with the server manager. As will be discussed, 
this reduces the number of requests which must be managed 
by the central database. In another embodiment of the 
invention, dynamic DNS updates are possible and IP 
addressing is integrated with DNS and DHCP management. 
All configuration changes, whether made statically, dynami- 
cally or at remote locations, are registered in the central 
database and automatically distributed to the appropriate 
servers. Also, DHCP redundancy guarantees that a DHCP 
server is always serving a given range of client addresses. 
Primary and backup DHCP servers serve the same address 
range which ensures that DHCP clients in the range can 
always acquire an IP address. Internet Service Providers 
(ISP) can benefit from the present invention because man- 
agement of IP address space is simplified. DHCP servers can 
act as both DHCP and Bootstrap Protocol (BootP) servers 
which enables ISPs to integrate the static allocation of IP 
addresses to cable modems through BootP with the dynamic 
allocation of IP addresses to end users through DHCP. The 
present invention also will be of great importance in such 
applications as Voice/Fax Over IP and Policy-Enabled Net- 
working where a user needs an authenticated address to 
access network services. 

In the described embodiment, the network includes a 
server manager 201, one or more DNS servers 202 A-N, one 
or more DHCP servers 203A-N, a central database 204, a 
NMS 205, one or more clients 208, a Lightweight Directory 
Access Protocol (LDAP) server 209 and a LDAP database 
210. The one or more DNS servers 202A-N and DHCP 
servers 203A-N are coupled in communication with the 
server manager 201 through individual communication 
channels. The server manager 201 is coupled in communi- 
cation with the central database 204 over a single commu- 
nication channel 206 and the NMS 205 over a single 
communication channel 207. The LDAP server 209 is 
coupled in communication with the server manager 201 over 
a single communication channel 211. However, in alterna- 
tive networks, the LDAP server 209 can communicate 
directly with the central database 204. 

The central database 204 may be any number of conven- 
tional databases. In the described embodiment, either a 
Sybase 7.3 or 8.0, available from Sybase, Inc. of Emeryville, 
Calif, or Oracle 11.x database, available from Oracle Cor- 
poration of Redwood Shores, Calif., is utilized to store 
network configuration information. The configuration infor- 
mation may include DNS and DHCP parameters, other 
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server parameters, IP addresses, domain names, the opera- 
tional status of servers that have successfully logged in to the 
network and the like. In the described embodiment, the 
central database 204 is relational and stores changes in 

5 configuration made to the network. Because the central 
database 204 is relational, it can log any configuration 
changes in a separate area. For purposes of this disclosure, 
the section of the central database 204 that contains the log 
of changes in configuration will be referred to as the 

10 delta-logging facility. Since changes in configuration in the 
network are stored in the delta-logging facility, audit records 
can be kept accurately and the server manager 201 can 
restore the central database 204 to a previously known state. 
For example, if the central database becomes corrupted, the 

is server manager can search the delta logging facility for the 
configuration information of a previously known uncor- 
rupted state. 

In the described embodiment, the one or more DNS 
servers 202A-N are Berkeley Internet Name Domain 

20 (BIND) 4.9.5 DNS servers, BIND 8.1.1 DNS servers or the 
like. These servers 202A-N communicate with the central 
database 204 through the server manager 201. Each DNS 
server is coupled to the server manager 201 through a TCP 
link. The TCP links from the servers 202A-N to the server 

25 manager 201 enable dynamic DNS updates and dynamic 
DNS reconfiguration. In the described embodiment, the one 
or more DHCP servers 203A-N are based on the BootP. 
These servers 203A-N also communicate with the server 
manager 201 through a TCP link and update the central 

30 database 204 with changes in DHCP configuration. 3 The 
ability of the DHCP servers to update the central database 
with configuration changes enables incremental synchroni- 
zation of DNS and DHCP services. The servers that can be 
linked to the server manager are not limited to DNS and 

35 DHCP servers. For example, a similar configuration could 
be used to support Remote Access Dial In User Services 
(RADIUS), Policy and future servers through the use of 
protocol server plug-in technology. 

The server manager 201, DNS 202A-N and DHCP 

40 203A-N servers described in the embodiment may, for 
example, run on the operating systems and hardware plat- 
forms given in Table 1. 



TABLE 1 



50 



Operating System 


Minimum Processor 


Minimum Memory 


Solaris 2.5, 2.6 


Sun Sparc 20 


64 Mb 


HP - UX 10.x 


Hewlett Packard 600 


64 Mb 


Windows NT 4.0 


Pentium 166 


64 Mb 



In the described embodiment, the DNS servers 202A-N 
and DHCP servers 203 A-N must first login with the server 
manager 201. If the login process is successful, the servers 

55 2 02A-N, 203 A-N must set their server id in able to issue 
command and requests to the server manager 201 for 
processing. The following sections describe how the servers 
202A-N, 203A-N complete the login process and how they 
communicate with the server manager 201. It should be 

60 appreciated that the methods described can be performed in 
other ways without departure from the scope of the present 
invention. 

FIG. 3 provides a flow diagram illustrating steps utilized 
in the described embodiment for a server to server manager 
65 login process. The login process is not unique to one type of 
server and can be used by any server attempting to establish 
a communication channel with the server manger 201. First, 
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the one or more DNS servers 202A-N and DHCP servers FIG. 4 provides a flow diagram which is useful for 

203 A-N establish a TCP link to the server manager 201, step describing a method of the described embodiment for trans- 

301. Next, each server 202A-N, 203A-N issues a login mining configuration information from the central database 

request by providing a userid and a password to the server 204 to a DHCP server 203A. 5 When the server manger 201 

manager 201, step 302. The password for each server 5 receives a request for configuration information from a 

202A-N, 203 A-N is only known by each individual server DHCP server 203 A, step 401, it checks to see if the server-id 

and the server manager 201. 4 The server manager 201 j s 7jdTOj s t e p 402. If the server-id is zero, the message is 

validates the userid and password by using MD5, which is ignored, step 403. 6 Otherwise, the server manager 201 

described in detail in Rivest, R., "The MD5 Message-Digest initiates a process to retrieve configuration information from 

Algorithm," Networking Group Request For Comments 30 the central database 204. The server manager 201 first 

(RFC) 1331, April 1992, to compute a digest value, step 303. receives information, such as range and host lists, from the 

If the password is correct, the server, for example a DNS DHCP server 203A, step 404. It then builds a subnet list 

server 202A, is logged in to the server manager 201, step associated with the DHCP server 203A based on the range 

305. If the password is incorrect, the login fails and the anc j host lists, step 405. Finally, it builds a network list 

server manager 201 drops the TCP link, step 304. In order 15 associated with the DHCP server 203A based on the subnet 

to retry the login sequence, the server 202A must reinitiate list, step 406, The server manager 201 then requests the 

a TCP link to the server manager 201 and start the login configuration information from the central database 204 

process from the beginning, step 301. based on the lists provided by the DHCP server 203A and the 

After logging in with the server manager 201, each DNS lists it created, step 407. The central database 204 transmits 

server 202 A-N and DHCP server 203 A-N must set their 2 o configuration information requested by the server manager 

server-id, step 306. Each server- id is checked against all of 201, step 408, and this information is sent to the DHCP 

the DNS and DHCP servers already coupled in communi- server 203 A requesting the configuration information, step 

cation with the server manager 201, step 307. If the server-id 409. In one embodiment, the configuration information can 

is the same as a server- id for a server already on the network, consist of (1) the global options for the network, which is 

the TCP link for the requesting server will be dropped, step 25 sent to the requesting server and the backup server serving 

308. If the server-id is unique to that server, the login process the same address ranges, if DHCP redundancy is supported, 

is complete, step 309. (2) the network options for each network contained in the 

Once the DNS servers 202A-N and DHCP servers network list that was created by the server manager, (3) the 

203A-N establish a link with the server manager 201, the subnet options for each subnet contained in the subnet fist, 

servers can issue requests for configuration information 30 (4) the range options for each range contained in the range 

from the central database 204 or send updated configuration list and (5) the host options for each host contained in the 

information to the central database 204. The server manager host list. A benefit of processing all requests for configu- 

201 synchronizes all of the requests and updates from the ration information from the central database 204 by the 

servers and transmits them to the central database 204. The DHCP servers 203A-N in the server manager 201 is that the 

server manager 201 monitors all the DNS servers 202A-N 35 load on the central database 204 is reduced. The server 

and DHCP servers 203A-N on the network from a single manager 204 eliminates the active link between every DHCP 

point and acts as a single pipeline to the central database server 203 A-N that needs configuration information from 

204. For example, when a new client 208 sends a request for the central database 204. 

an IP address to a DHCP server 203A, the DHCP server The server manager 201 also notifies each DHCP server 
203A determines if it can send configuration information to 40 203A-N of any changes to the central database 201. Once 
the requesting client 208. If the DHCP server 203 A can give the DHCP servers 203A-N have logged in with the server 
an IP address and configuration information to the client manager 201, the server manager 201 polls the delta- logging 
208, it sends host configuration information and an IP facility in the central database 204 for configuration changes 
address to the client 208. The DHCP server 203 A automati- made to the network that would effect the DHCP servers 
cally registers the new domain name, the IP address and the 45 203A-N coupled in communication with the server manager 
host configuration information with the central database 204 201. The interval in between polling can be either a default 
through the server manager 201. The DNS server 202A value or a value set by a user such as the network admin- 
detects the new IP address through the server manager and istrator. In the described embodiment, the interval between 
updates its DNS information. When the lease expires or the each time the server manager 201 polls the central database 
client 208 leaves the network and releases the IP address, the 50 204 for configuration changes is 60 seconds. FIG. 5 provides 
DHCP server 203A notifies the central database 204 of the a flow diagram which illustrates a method of the described 
change through the server manager 201. The IP address is embodiment for retrieving any changes in configuration 
available for reassignment by the DHCP server 203A to a made to the network from the delta-logging facility in the 
new client. Therefore, the server manager 201 eliminates the central database 204 and transmitting them to the DHCP 
need for the individual DNS servers 202A-N and DHCP 55 203A-N servers coupled in communication with the server 
servers 203A-N to establish direct communication channels manager 201. Once at least one of the DHCP servers 
with the central database by providing access to the central 203A-N is communicating with the server manager 201, the 
database 204 through one communication channel 206. server manager 201 queries the delta-logging facility in the 
(more????) central database 204, step 501, to determine if there were 
Advantageously, the described embodiment utilizes plug- 60 any configuration changes, step 502. If there were changes 
in technology in order to allow support for current as well as in configuration, the server manager 201 issues a request to 
future generation servers. The DHCP server plug-in has the central database 204 for the global range information, the 
three functions: (1) Provides configuration information to network information, the global client pool and each client 
the DHCP servers linked to the network; (2) Informs the pool and client pool entry managed by the DHCP servers 
DHCP servers of any relevant changes in the central data- 65 203A-N, step 503. B Depending on what configuration 
base; and (3) Transacts the DHCP hosts into the central changes occurred in the network, the server manager 201 
database. retrieves the appropriate information, step 504 and distrib- 



02/23/2004, EAST version: 1.4.1 



US 6,374,295 B2 

7 8 

utes it to the appropriate DHCP 203A-N servers. 9 If the 603. However, if the server id is a valid domain name and 
server manager 201 finds no changes or has completed the version number is valid, the server manager 201 receives 
distributing the changes to the DHCP server 203A-N, it the primary and secondary zones managed by the DNS 
waits the set interval of time and polls the delta-logging server 202A, step 604. The server manager 201 then issues 
facility again for changes, step 501. A benefit of only 5 a configuration update request for each zone managed by the 
allowing the server manger 201 to pool the delta-logging DNS server 202A to the central database 204, step 60S. The 
facility for changes in configuration is that the load on the central database 204 transmits the configuration information 
network is reduced. The reduced load and reduced amount for each zone to the sever manager 201, step 606. The server 
of traffic to the database increases the overall performance of manager 201 then transmits the updated configuration infer- 
tile network because the server manager 201 automatically 10 mation to the DNS server, step 607. For each primary 
determines which DHCP servers 203A-N are effected by the forward zone, the server manger 201 sends the Start of 
changes. This eliminates update requests from DHCP serv- Authority (SOA) record, name servers of the zone, the A 
ers that are not affected by the configuration changes made record, 15 RR record, option record, CNAME record and the 
to the network. glue record with the subzones to the DNS server 202 A. 16 

The server manager 201 also processes host commit is For each P rimarv reverse zone, the server manager 201 

requests from DHCP servers 203A-N. 10 In order to add host sends the 202A record, name servers of the zone, the PTR 

information to the central database 204, the server manager record for each subdomain of the zone and the glue record 

201 must determine if the domain name is available, with the subzones to the DNS server 202A. For each 

unavailable, moving from another host or being updated. secondary zone, the server manager 201 sends that zone 

Upon receiving a request from a DHCP server 203A to add 2 0 lransfer list 10 the DNS server 202A. Finally, the server 

a host, the server manager 201 first checks if the domain is manager 201 sends information about the root server on the 

a Canonical Name (CNAME) or primary name. If the network to the DNS server 202A. 17 

domain is a CNAME, it fails validation and the server The server manager 201 also polls the delta-logging 

manager 201 notifies the DHCP server 203A that the domain facility in the central database 204 periodically to determine 

is unavailable. 11 If the domain does not exist in the central 2 5 if tnere were aav changes in configuration made to the 

database 204, the label 12 may be assigned to the host and the network that would effect the DNS servers 202A-N. The 

server manager 201 notifies the DHCP server 203A that the process of polling the delta-logging facility in the central 

domain is available. If the client-id of the host requesting the database 204 for the DNS servers 202A-N is similar to the 

label is the same as the client-id of the host in the central process previously described in FIG. 5 for the DHCP servers 

database 204 that owns the label, the label may be assigned 30 203A-N. However, the server manager 201 requests the 

to the requesting host and the server manager notifies the primary and secondary zone information, the primary for- 

DHCP server 203A that the domain is available. If the host ward and reverse zone information, the subzone information 

in the central database 204 is static, the label can't be used for each subzone not managed by a DNS server and the 

and the server manager 201 notifies the DHCP server 203A subdomain of one of the primary zones managed by the DNS 

that the domain is unavailable. If the IP addresses match, the 35 server. Once the server manager 201 retrieves this 

label is updated and the server manager 201 notifies the information, it transmits the relevant information to the 

DHCP server 203A that the domain has been updated. If the appropriate DNS servers 203A-N. 18 This method has a 

IP addresses do not match, the label is moved to the similar benefit, as described above in the DHCP section, in 

requesting host and the server manager 201 notifies the that DNS servers that are not effected by the configuration 

DHCP server 203A that the domain has been moved. If the 40 changes will not be polling the central database 204 for 

client-id of the host requesting the label is not the same as changes since the only server manager 201 is coupled in 

the client-id of the host in the central database that owns the communication with the central database 204, 

label, the label is in use and may not be assigned to the host. The server manager 201 can process multiple requests or 

The server manager 201 notifies the DHCP server 203A that commands at the same time. However, the number of 

the domain is unavailable. If the server manager 201 deter- 45 requests or updates that the server manager 201 can process 

mines that the domain name is available, the server manager at the same time is determined by the machine that it is 

adds the new host to the network by (1) setting the host IP running on. Therefore, the server manager 201, as used by 

address; (2) assigning a client-id to the host; (3) setting the the described embodiment, prioritizes what it processes 

hardware address; (4) setting the DHCP server-id; (5) based on the type of work requested. The server manager 

assigning a lease expire time; and (7) determining a domain 50 201 services the requests and updates in the following order: 

name. 13 The server manager 201 will then validate all of the (1) get configuration requests from the DCHP servers; (2) 

above information. If the validation fails, the server manager polling the central database for any configuration changes in 

201 notifies the DHCP server 203A that the host commit the network; (3) configuration update requests from the DNS 

failed, otherwise the server manager 201 notifies the DHCP servers; and (4) removing leases for IP addresses when they 

server 203A that the host has been committed and transmits 55 expire. 19 Prioritizing based on the type of work requested is 

the host information to the central database 204. not the only method available for the server manager 201 to 

The DNS server's plug-in has two functions: (1) Provides process information. It could also process the information 

format configuration information to the both the BIND 4.9.5 based on a first-in first-out method. For example, the first 

DNS servers and the BIND 8.1.1 DNS servers; and (2) request or packet of information received by the server 

Informs them of the relevant changes in the central database. 60 manager 201 would be processed first and the last request or 

FIG. 6 provides a flow diagram which is useful for describ- packet of information received by the server would be 

ing a method of the described embodiment for communi- processed last. 

eating configuration updates from the central database 201 The server manager 201 also has the ability to actively 

to a DNS server 202A. 14 When the server manager 201 manage the DNS 202 A to 202N and DHCP 203 A-N servers 

receives a configuration update message from a DNS server 65 and report their operational status to the NMS 205. In the 

202A, step 601, it checks to see if the server id is valid, step described embodiment, the NMS 205 communicates with an 

602. If the server-id is NULL, the message is ignored, step agent, the server manager 201, to keep track of the network 
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statistics and resources. Network administrators can use the 
NMS 205 to view the real-time operating status of the DNS 
202A-N and DHCP 203 A-N servers that are linked with the 
server manager 201. In one embodiment, the NMS 205 
could be a graphical user interface (GUI) running on a 5 
powerful computer such as a workstation. FIG. 7 provides a 
flow diagram which illustrates a method of the described 
embodiment for determining the operational status of the 
DNS 202A-N and DHCP 203A-N servers on the network 
and transmitting the status information to the NMS 205. The 10 
server manager 201 polls the servers every 40 seconds to 
determine if the server is still running or if it has stopped, 
step 701. 20 The server generates an alarm or warning to 
indicate its operating status and communicates the message 
to the server manager 201, step 702. The message could 15 
contain information such as a key word to trigger the correct 
plug-in, the severity of the alarm, the specific server-id, and 
an alarm code to indicate the problem. The server manager 
201 queues up the reports from the servers along with any 
other requests that it receives and attaches a database time 20 
stamp to each one. The server manager 201 then commu- 
nicates the alarms to the central database 204 and to the 
NMS 205, step 703. 21 The alarms are sent to the NMS 205 
through a Simple Network Management Protocol (SNMP) 
trap. The traps could contain information such as setting the 25 
server status to up when the server successfully establishes 
a TCP link with the server manager 201, setting the server 
status to down when the TCP link between the server and the 
server manager is dropped and setting the server status to 
failed login when the server successfully establishes a TCP 30 
link with the server manager 201 but tried an invalid login. 
These traps can then be viewed from the GUI by the network 
administrator. The advantage to using the server manager 
201 for active server management is that the server manager 
201 can detect when a server has crashed. In some 35 
embodiments, multiple servers are running on the same 
hardware. If the hardware is still running but one of the 
servers has crashed, the server manager 201 can detect the 
chance through the TCP link which will be dropped if the 
server crashes. When the TCP link is started or dropped, the 40 
server manager 201 generates an exception, such as the 
described SNMP traps, to the NMS 205. Therefore, the 
network administrator is able to determine if a server has 
gone down if the hardware is still operational. 

The present invention also allows a user to be authenti- 45 
cated and binds the user to the IP address that was given to 
it by the DHCP server on the network. FIG. 8 provides a 
flow diagram which illustrates a method of the described 
embodiment for authenticating a user and binding the user to 
their current address. First a client 208 requests an IP address 50 
from the DHCP server 203N on the network, step 801. The 
DHCP server 203N dynamically assigns the client 208 an IP 
address before it has been authenticated, step 802. The client 

208 then issues a registration request with the binding server 

209 and communicates its userid, password and the IP 55 
address it just obtained from the DHCP server 203N to the 
binding server 209, step 803. The method of communication 
used by the client in the described embodiment is the Hyper 
Text Transfer Protocol (HTTP) but alternative methods can 

be used. Currently the client does not provide itself with a 60 
userid or password. However, two examples of methods for 
the client to obtain its userid and password are to have the 
user go to a World Wide Web (WWW) page or download a 
Java applet to obtain information from a PC or workstation 
which could modify the operating system to automatically 65 
provide it. The binding server 209 then authenticates the 
userid, password and IP address through an LD AP request to 
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the LDAP database 210, step 804. The LDAP request 
searches the LDAP database 210 for the userid, password 
and the possible IP addresses that the DHCP server 203N 
could assign, step 805. The LDAP database 210 is organized 
in a tree hierarchy. For example, the root of an Internet 
address is at the top and the common name associated with 
the user is at the bottom. The LDAP database 210 is 
accessible through an open, standards based protocol such as 
TCP. If the information is found in the LDAP database 210, 
it notifies the binding server 209 that the user credentials 
were verified by returning the authenticated credentials, step 
807 . 22 The binding server 209 then sends the authenticated 
credentials to be stored in the central database 204, step 808. 
In the described embodiment, the binding server 209 com- 
municates with the server manager 201 over a single channel 
211 to store the credentials in the central database 204. 
However, the binding server 209 could also communicate 
directly or through some other device with the central 
database 204 in order to store the authenticated credentials. 

The present invention as utilized in the described embodi- 
ment authenticates the actual userid/password and address 
combination. Applications such as Voice/Fax over IP and 
Video Conferencing can benefit from the present invention 
because routing and bandwidth considerations are based on 
source and destination addresses. Therefore, deciding which 
users can access the network services requires authenticated 
addresses. 

Thus, method and apparatus for transmitting configura- 
tion between a central database and one or more servers 
through a server manager on a network has been described. 
Although the present invention has been described with 
specific reference to a number of details of the preferred 
embodiment and with reference to FIGS. 1 through 8, it will 
be apparent to those skilled in the art that a number of 
modifications and various variations may be employed with- 
out departure from the scope and spirit of the present 
invention. 

What is claimed is: 

1. A method of providing an update of a network protocol 
address information stored in a central database to one or 
more network protocol address management servers, com- 
prising: 

periodically checking whether said network protocol 
address information has been updated since a previous 
check of said network protocol address information; 
and 

transmitting said updates of said network protocol address 
information to said one or more network protocol 
address management servers which said update corre- 
sponds to. 

2. The method of claim 1, wherein said periodically 
checking comprises querying a delta-logging facility in said 
central database for any changes to said network protocol 
address information. 

3. The method of claim 1, further comprising issuing a 
request for said update to said central database. 

4. The method of claim 3, wherein said update comprises 
global range information, network information, and/or glo- 
bal client pool. 

5. The method of claim 1, wherein said one or more 
network protocol address management servers each com- 
prises a Dynamic Host Configuration Protocol (DHCP) 
server, and said network address protocol information 
includes DHCP parameters. 

6. The method of claim 1, wherein said one or more 
network protocol address management servers each com- 
prises a Domain Name Service (DNS) server, and said 
network protocol address information includes DNS param- 
eters. 
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7. The method of claim 1, further comprising synchro- 17. A network, comprising: 

nizing transmissions of requests for network protocol a centfal database for storiog Detwork protocol address 

address informaUon to said central database sent from said information relating t0 said network; 

one or more network protocol address management servers. 6 ' 

8. The method of claim 7, further comprising prioritizing 5 one or more network protocol address management serv- 
said requests for network protocol address information prior ers; and 

to said transmission of requests for said network protocol a sefver manager for providing an update of said network 

address information to said central database ^ informalion stored iD aid cenlral 

9. A server manager for providing an update ot a network *, . ., . 4 , 
protocol address information stored in a central database to in database t0 531(1 one or more mt ™* P rotoco1 address 
one or more network protocol address management servers, 10 management servers, wherein said server manager: 
said server manager: periodically checks whether said network protocol 

periodically checks whether said network protocol address information has been updated since a previous 

address information has been updated since a previous check of said network protocol address information; 

check of said network protocol address information; and 

j 15 

. . , * . , i transmits said updates of said network protocol address 

transmits said updates of said network protocol address . ~ . _ nr mnra „ mt „„„i 

« /• . • j r . , , information to said one or more network protocol 
information to said one or more network protocol ; 
address management servers which said update corre- address management servers which said update corre- 
sponds to. s P° nds to - 

10. The server manager of claim 9, wherein said server 20 18- The network of claim 17, wherein said server manager 
manager in periodically checking whether said network in periodically checking whether said network protocol 
protocol address information has been updated queries a address information has been updated queries a delta- 
delta-logging facility in said central database for any logging facility in said central database for any changes to 
changes to said network protocol address information. sa i d network protocol address information. 

11. The server manager of claim 9, wherein said server 25 19 ^ netW ork of claim 17, wherein said server manager 
manager issues a request for said update to said central a { fof said date tQ ^ 

Qstflnsse 

12. The server manager of claim 11, wherein said update 20 The netwoik of claim 17, wherein said update corn- 
comprises global range information, network information, P nscs S 10 ^ 1 ra °g e information, network information, and/ 
and/or global client pool. 30 or § lobal chent P°° l 

13. The server manager of claim 9, wherein said one or 21. The network of claim 17, wherein said one or more 
more network protocol address management servers each network protocol address management servers each corn- 
comprises a Dynamic Host Configuration Protocol (DHCP) prises a Dynamic Host Configuration Protocol (DHCP) 
server, and said network protocol address information server, and said network protocol address information 
includes DHCP parameters. 35 mcaJ des DHCP parameters. 

14. The server manager of claim 9, wherein said one or 22 ^ network of claim 17f wherein said one or more 

more network protocol address management servers each netWQrk ^ a(ldress ma ment xrvm each con> 

comprises a Domain Name Service (DNS) server, and said a Domam Name Service ( afld safd 

network protocol address information includes DNS param- a ■ r i j Y^to 

eiefs y r configuration information includes DNS parameters. 

C 'is. The server manager of claim 9, wherein said server 40 23 TTie network of claim 17, wherein ^said server manager 

manager synchronizes transmissions of requests for network synchronizes transmissions of requests for network protocol 

protocol address information to said central database sent address information to said central database sent from said 

from said one or more network protocol address manage- one or more network protocol address management servers, 

ment servers. 24. The network of claim 23, wherein said server manager 

16. The server manager of claim 15, wherein said server 45 prioritizes said requests for network protocol address infor- 

manager prioritizes said requests for network protocol mation prior to said transmission of requests for said nel- 

address information prior to said transmission of requests for work protocol address information to said central database, 
said network protocol address information to said central 

database. ***** 
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